Page history of 윈도우 개발환경 삽질기

드디어 삼성 노트북 펜 15인치가 도착해서 세팅을 시작했다. 목표는 맥/리눅스에 근접할 정도로 편리한 개발 환경을 구축하는 것. 필요한 개발 환경은 대충 다음과 같은 것들이다.

• 파이썬
• node.js 기반의 프론트엔드 도구
• 안드로이드 앱
• electron 기반의 데스크탑 앱
• 윈도우 앱 automation (pywinauto 등으로)
• 머신러닝 (1~2년 후에 필요)
• iOS? (가능한 방법이 있을까?)

이 중에 가장 중요한 것은 물론 파이썬이다. 파이썬 개발 환경 구축을 위해서는 다음과 같은 것들이 필요하다.

• git, ssh
• python >= 3.6
• pycharm에서 project interpreter 지정이 가능할 것
• 파이썬 패키지에서 사용하는 네이티브 라이브러리들, postgresql이나 rabbitmq 등 posix 기반에서 개발된 소프트웨어들
• 좋은 커맨드라인 인터페이스

파이썬 다음으로 중요한 것은 node.js 기반 도구들인데, 파이썬과 요구사항은 비슷하다. 이런 요구사항을 소화하기 위해 가능한 옵션은 다음과 같은 것들이 있다.

• VirtualBox
• cygwin
• Windows 네이티브 + 커맨드라인 보조 툴(mingw 등) + Visual Studio(C/C++ Compiler)
• Windows Subsystem for Linux

내가 이상적이라고 생각하는 방안은 cygwin이다. 하지만 cygwin은 최신 패키지 지원이 한 박자 늦고 지원되는 패키지 수가 적다. 어차피 Window 네이티브와의 조합이 필요하다면 굳이 파이썬을 cygwin으로 설치해서 얻는 이득이 별로 없다. 그래서 cygwin은 시도해보지 않는다. VirtualBox는 아무리 좋아졌다고는 하나 여전히 느리고 스위칭이 불편하기 때문에 다른 모든 방법에 나쁘다고 판단할 경우에만 선택할 것이다. Windows 네이티브는 이미 여러 번 실험해봐서 가능하고 약간 불편하지만 그럭저럭 쓸만하다는 사실을 알고 있는 상태다. WSL은 bash.exe를 통해서만 리눅스 바이너리를 실행할 수 있다는 치명적인 단점(이것 때문에 PyCharm에서 직접 local interpreter로 지정할 수 없다)이 있지만 그 단점은 일부분 회피 가능하고, 윈도우 개발툴로 편집하고 리눅스 서버로 돌아가는 상황을 VirtualBox보다 좀더 매끄럽게 연출할 수 있다. 그래서 WSL 세팅을 먼저 시작해보았다.

Windows Subsystem for Linux

WSL의 가장 큰 장점은 무거운 가상머신 없이 리눅스와 윈도우의 상호운용이 가능하다는 것이다. VirtualBox 같은 가상머신이 들어가면 SSH와 공유 폴더를 통해 상호운용을 해야 하는데, 참을 만한 정도이기는 해도 개발자는 이 정도 편리함에 만족해서는 안된다고 생각한다. 그래서 윈도우 native를 이용할 때의 장점을 하나도 잃지 않으면서 Linux의 장점도 같이 살릴 방법을 찾기로 했다.

WSL을 그냥 사용하는 방법은 간단하다. WSL을 활성화하고 ubuntu를 설치해서 ubuntu를 실행하면 bash.exe가 실행된다. 이 bash.exe 안에서는 완전한 linux처럼 쓸 수 있다. 초기에는 패키지가 다소 부족했지만이제 개발에 필요한 대부분의 우분투 패키지를 지원한다. X 서버가 지원되지 않지만 GUI 도구는 윈도우를 쓸 것이기 때문에 별 문제 없다. 쉘도 bash니까 충분히 편리하다. 쉘을 띄우는 터미널은 여전히 cmd 기반이지만 예전과 달리 창 크기 조절도 되고 별 문제는 없다. 여기까지는 OK.

가장 결정적인 문제는 PyCharm과 같은 IDE에서 연동하는 것이다. WSL에서 sshd를 띄우고 remote로 사용하는 것은 원래부터 가능하다. 

Windows 네이티브 개발환경

Windows 네이티브로 개발환경을 구축한다는 것은 리눅스 호환 시도를 하지 않고 윈도우용으로 빌드된 소프트웨어를 설치해서 사용한다는 것이다. 가장 윈도우스러운 방법이지만 posix 계열 개발자들이 윈도우에서 되도록 하고 싶어하지 않는 일이기도 하다. 하지만, 과거의 경험을 떠올려봐도 윈도우용으로 직접 빌드된 소프트웨어를 쓸 때 가장 안정적이긴 했다. 다만, 이 경우 posix 계열에 비해 크게 불편한 점이 여러 가지 있다.

패키지 관리

가장 심각한 문제는 개발에 필요한 패키지를 직접 설치하는 것이 몹시 번거롭다는 것이다. 내가 지금 작업하고 있는 프로젝트를 제대로 돌리려면 파이썬, PostgreSQL, RabbitMQ, Redis, Java, Node.js, yarn 등이 잘 설치되어야 하는데, 윈도우에서는 각각 바이너리를 받아서 설치하려면 몹시 귀찮다. 리눅스라면 apt, 맥에서는 brew로 매우 손쉽게 해결되는 일인데, 윈도우는 그게 어렵다. 그래도 이런 것들은 한 번 설치하면 다시 건드리는 일이 드물어서 1년에 몇 번 안되는 일이긴 하다. 그래서, 수동으로 관리하는 것도 선택지이긴 하다. 그러나, 윈도우에도 brew와 같은 시도가 여러 가지 있기 때문에 실험을 해보기로 했다.

가장 먼저 써본 것은 인지도가 가장 높고 패키지 수도 가장 많은 chocolatey였다. 하지만 뭐가 문제인지 패키지 설치가 제대로 되지 않거나, 너무 오래걸리거나, 오래 걸리는데 진행률 피드백이 제대로 나오지 않았고, 매번 관리자 권한으로 powershell을 열어야 하는 것도 귀찮았다. 그래서 scoop으로 넘어갔다. 이미 파이썬과 PostgreSQL은 설치한 상태여서 node.js와 yarn을 시도해보았는데 아주 깔끔하게 잘 설치되었다. 이 정도면 brew만은 못하지만 그럭저럭 만족할 수 있을 것 같다.

패키지 관리 방안 해결: scoop으로 먼저 install 해보고 없으면 수동으로 설치파일 받아서 설치한다.

터미널

두번쨰 문제는 터미널(과 쉘)이다. 옛날옛적의 cmd는 허접하기 그지 없었는데, 특히 가장 결정적인 문제는 창 크기 조절이 제대로 안된다는 거였다. 가로폭을 자유롭게 조정할 수 없었다. 다행히 이제 그 문제는 해결되어 있다. 하지만 여전히 맥이나 리눅스에 비하면 허접하기 그지 없다. 다만, 이 문제는 좀 나누어서 생각할 필요가 있다. 커맨드라인의 역할을 터미널과 쉘로 나누어서 본다면 터미널 쪽은 이제 쓸만하다. 창 크기 조절, 폰트 설정, copy & paste 등 큰 문제는 없다. 딱 한 가지 부족한 점은 탭이 안된다는 것이다. 개발하다보면 한 프로젝트에서 여러 개의 터미널을 열어야 하는 경우가 많아서 나는 보통 프로젝트당 하나의 터미널 윈도우를 열고 그 안에서 탭으로 해당 프로젝트에 필요한 터미널들을 연다. 윈도우는 이게 안된다. 이건 git과 함께 설치되는 bash도 마찬가지고, WSL의 bash도 마찬가지다. 이 문제를 해결하려면 별도의 터미널 소프트웨어를 써야 한다. PowerShell ISE를 쓰면 탭은 되지만 조금 무겁고 runserver에서 

쉘 쪽은 cmd든 powershell이든 둘다 bash에 비해 압도적으로 불편하다.